Risk Analysis

Technical Definitions:

Risk Analysis: A risk analysis involves identifying the most probable threats to an organization and analyzing the related vulnerabilities of the organization to these threats.

Risk Assessment: A risk assessment involves evaluating existing physical and environmental security and controls, and assessing their adequacy relative to the potential threats of the organization.

Business Impact Analysis: A business impact analysis involves identifying the critical business functions within the organization and determining the impact of not performing the business function beyond the maximum acceptable outage. Types of criteria that can be used to evaluate the impact include: customer service, internal operations, legal/statutory and financial.

Risks for a software product can be categorized into various types. Some of them are:

Product Size Risks:

The following risk item issues identify some generic risks associated with product size:

• Estimated size of the product and confidence in estimated size? 
• Estimated size of product? 
• Size of database created or used by the product? 
• Number of users of the product? 
• Number of projected changes to the requirements for the product?

Risk will be high, when a large deviation occurs between expected values and the previous experience. All the expected information must be compared to previous experience for analysis of risk.

Business Impact Risks:

The following risk item issues identify some generic risks associated with business impact:

• Affect of this product on company revenue? 
• Reasonableness of delivery deadline? 
• Number of customers who will use this product and the consistency of their needs relative to the product? 
• Number of other products/systems with which this product must be interoperable? 
• Amount and quality of product documentation that must be produced and delivered to the customer? 
• Costs associated with late delivery or a defective product?

Customer-Related Risks:

Different Customers have different needs. Customers have different personalities. Some customers accept what is delivered and some others complain about the quality of the product. In some other cases, customers may have very good association with the product and the producer and some other customers may not know. A bad customer represents a significant threat to the project plan and a substantial risk for the project manager.

The following risk item checklist identifies generic risks associated with different customers:

• Have you worked with the customer in the past? 
• Does the customer have a solid idea of what is required? 
• Will the customer agree to spend time in formal requirements gathering meetings to identify project scope? 
• Is the customer willing to participate in reviews? 
• Is the customer technically sophisticated in the product area? 
• Does the customer understand the software engineering process?

Process Risks:

If the software engineering process is ill-defined or if analysis, design and testing are not conducted in a planned fashion, then risks are high for the product.

• Has your organization developed a written description of the software process to be used on this project? 
• Are the team members following the software process as it is documented? 
• Are the third party coders following a specific software process and is there any procedure for tracking the performance of them? 
• Are formal technical reviews are done regularly at both development and testing teams? 
• Are the results of each formal technical review documented, including defects found and resources used? 
• Is configuration management used to maintain consistency among system/software requirements, design, code, and test cases? 
• Is a mechanism used for controlling changes to customer requirements that impact the software?

Technical Issues:

• Are specific methods used for software analysis? 
• Are specific conventions for code documentation defined and used? 
• Are any specific methods used for test case design? 
• Are software tools used to support planning and tracking activities? 
• Are configuration management software tools used to control and track change activity throughout the software process? 
• Are tools used to create software prototypes? 
• Are software tools used to support the testing process? 
• Are software tools used to support the production and management of documentation? 
• Are quality metrics collected for all software projects? 
• Are productivity metrics collected for all software projects?

Technology Risk:

• Is the technology to be built new to your organization? 
• Does the software interface with new hardware configurations? 
• Does the software to be built interface with a database system whose function and performance have not been proven in this application area? 
• Is a specialized user interface demanded by product requirements? 
• Do requirements demand the use of new analysis, design or testing methods? 
• Do requirements put excessive performance constraints on the product?

Development Environment Risks:

• Is a software project and process management tool available? 
• Are tools for analysis and design available? 
• Do analysis and design tools deliver methods that are appropriate for the product to be built? 
• Are compilers or code generators available and appropriate for the product to be built? 
• Are testing tools available and appropriate for the product to be built? 
• Are software configuration management tools available? 
• Does the environment make use of a database or repository? 
• Are all software tools integrated with one another? 
• Have members of the project team received training in each of the tools?

Risks Associated with Staff Size and Experience:

• Are the best people available and are they enough for the project? 
• Do the people have the right combination of skills? 
• Are staffs committed for entire duration of the project?